home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Grand Slam 3
/
Grand Slam 3.iso
/
002
/
clno_151.arj
/
CLEANOUT.DOC
< prev
next >
Wrap
Text File
|
1995-07-30
|
36KB
|
918 lines
┌╦═══╦┐┌╦ ┌╦═══╦┐┌╦═══╦┐┌╦═╗ ╦┐┌╦═══╦┐┌╦ ╦┐┌╔═╦═╗┐
│║ │║ ├╬══ ├╬═══╬┤│║ ║ ║││║ ║││║ ║│ ║
└╩═══╩┘└╩═══╩┘└╩═══╩┘└╩ ╩┘└╩ ╚═╩┘└╩═══╩┘└╩═══╩┘ ╩
Version 1.51
Program and documentation (C) 1995 by Klaus Nitsche & BearWare
╒════════════╕
│ BearWare │
╘════════════╛
A utility to keep your Binkley-style outbound directories clean
If you are in a hurry to get things going, read the "Quick Start"
section below. If everything falls to pieces then, come back and read
the whole documentation. <grin>
┌─────┬────────────────────────────────────────────────────────────────┐
│ 1 │ IMPORTANT NOTE │
└─────┴────────────────────────────────────────────────────────────────┘
CleanOut is a DANGEROUS tool!
─────────────────────────────
Its main purpose involves deleting files. Currently this is done in a
quick and painless way; future versions might have the ability to apply
more elegant methods, such as roasting them slowly. (I have a sadistic
nature.)
It is assumed that you are well familiar with the way Binkley-style mailers
handle their outbound. If you run a FrontDoor-style mailer or other exotic
pieces of software, CleanOut will not only be of no use to you, but will
probably also cause great harm on your system.
┌──────────────────────────┐
│ YOU HAVE BEEN WARNED ! │
└──────────────────────────┘
The currently supported mailers are:
────────────────────────────────────
■ BinkleyTerm and its several hacks and derivatives
■ Xenia 1.98
■ McMail 1.0 gamma
■ Portal of Power (PoP) 0.62 (untested, but should work)
If you run any other Binkley-style mailer, DON'T use this program (it might
kill files that your mailer needs) and contact me. Send me all the
information you can scrape together concerning what kind of files your
mailer uses to handle its outbound, and I will incorporate it into
CleanOut.
Minimum system requirements for running CleanOut:
─────────────────────────────────────────────────
■ MS-DOS 3.0 or up. CleanOut uses SHARE function calls which aren't
available in older versions of MS-DOS. If you use a multitasking
environment, you must load SHARE.EXE (and if you don't, you should, or
you might run into BIG trouble)
■ or OS/2 (any version). CleanOut is a DOS program and must be run in a
DOS task. (Yeah yeah, I know. There will be a version of CleanOut for
you PROTECTONLY folks some time, but don't hold your breath, okay?)
Tested environments
───────────────────
CleanOut has been tested with the following mailers:
■ Xenia 1.98
■ McMail 1.0 gamma
■ BinkleyTerm 2.59a
... and in the following environments:
■ OS/2 Warp 3.0 (DOS box) with HPFS file system and FAT file system
■ MS-DOS 5.0, 6.22
■ 4DOS 5.0, 5.5c
■ QEMM 7.04
■ DESQView 2.63
■ Lantastic 6.0
■ Novell 3.11, 3.12
It might or might not run in other environments and with other mailers,
hey, can we be sure of anything these days?
┌─────┬────────────────────────────────────────────────────────────────┐
│ 2 │ QUICK START │
└─────┴────────────────────────────────────────────────────────────────┘
For you impatient folks out there, let's get this show on the road right
now. No warranties at all.
CleanOut will kill all files in your outbound directories (and some
other directories that you might want to specify) that your mailer
doesn't know about. They just lie around and waste space, so let's zap
them.
For safety reasons, you should run CleanOut ONLY during your nightly
maintenance when all your mailer tasks are down and your tosser sleeps.
■ Edit the sample config file CLEANOUT.CFG that came with the archive so
that it fits your needs, and put it in the same directory as
CLEANOUT.EXE.
■ I *STRONGLY RECOMMEND* that before you run CleanOut for the first
time, you specify
SIMULATE YES
and also a file name for a log file. That will allow you to run
CleanOut in merciful mode and not do any actual killing. Study the
program's output and the log file and see if that's what you wanted it
to do. Once you're satisfied, specify
SIMULATE NO
and you're own your own from there on.
■ Specify your name and FTN address(es).
■ Specify ALL of your mailer's outbound directories using the OUTBOUND
keyword. (This is IMPORTANT! I mean ALL OF THEM! Point directories
too!)
■ If you use any additional "queue" directories, specify them using the
SCANALSO keyword. Files found there will be deleted as well if your
mailer doesn't know them.
■ Make VERY sure that you don't specify any other directories here which
might have valuable files in them. They will be killed.
■ If you want CleanOut to delete old files, use the keyword "NukeDays".
If you set it to less than 14 days, manual interaction is required
when CleanOut runs (see below).
■ If you want CleanOut to write a warning to lazy downlinks some time
before their stuff gets nuked, use the keyword "WarnDays", and set it
lower than "NukeDays".
The config file is heavily commented, so if you're an experienced user,
that should get you going. If you have trouble understanding anything,
please come back here and read the documentation fully before
continuing.
┌─────┬────────────────────────────────────────────────────────────────┐
│ 3 │ THE DISTRIBUTION ARCHIVE │
└─────┴────────────────────────────────────────────────────────────────┘
CleanOut is distributed in an RAR archive that comes with a security
envelope. When extracting it (by typing RAR E CLNO_151.RAR), you should
have seen messages similar to these:
Verifying authenticity information ... Ok
Extracting from CLNO_151.RAR
Extracting CLEANOUT.CFG Ok
Extracting FILE_ID.DIZ Ok
Extracting CLEANOUT.DOC Ok
Extracting WHATSNEW.DOC Ok
Extracting CLEANOUT.DOK Ok
Extracting WHATSNEW.DOK Ok
Extracting CLEANOUT.EXE Ok
Extracting FLOWAGE.EXE Ok
Extracting REGISTER.RAR Ok
Archive CLNO_151.RAR
created at 15:20:10 30 Jul 1995
by Klaus Nitsche - The Bear's Cave
All OK
If you didn't see the message "Verifying ..." and the one with my name in
it, the archive has been tampered with. Delete it and obtain the correct
archive somewhere.
You can always get the current version in the original archive by file
requesting the magic file name CLEANOUT from the following systems:
The Bear's Cave I FidoNet 2:2461/161 BBS: 49-6144-92241
PB-Net 246:6104/1001
The Bear's Cave II FidoNet 2:2461/162 (ISDN, no BBS)
PB-Net 246:6104/1002
Com-Dat BBS FidoNet 1:105/314 BBS: 1-503-681-0543
1:105/317 BBS: 1-503-640-0278
1:105/330 BBS: 1-503-681-8324
Reptile Ranch FidoNet 1:256/102 BBS: 1-613-264-8513
CleanOut is also available via anonymous FTP from europa.com in the
directory /outgoing/bearware.
To obtain CleanOut via anonymous FTP, do the following:
ftp europa.com
Login as anonymous and use your e-mail address as the password. Then
change to the directory where CleanOut is by:
cd /outgoing/bearware
Be sure and give the 'binary' command before transferring the archive.
┌─────┬────────────────────────────────────────────────────────────────┐
│ 4 │ BEARWARE │
└─────┴────────────────────────────────────────────────────────────────┘
BearWare? Whuzzat?
───────────────────
CleanOut is BearWare. BearWare stands for software developed at the Bear's
Cave.
CleanOut is distributed under the shareware concept. You are entitled
to use it for a 30-day evaluation period. If you continue using it
after that, you must register it.
See the included archive REGISTER.RAR for information on how to
register.
Legalese
────────
CleanOut runs fine on my system and on those of the beta testers. But
(you guessed it) there are no warranties at all. Running it (and facing
the consequences) is your responsibility, and yours alone. I've taken a
number of measures to prevent CleanOut from killing important files
accidentally, but if it does, it's your own fault. I will only
guarantee that CleanOut uses a certain amount of room on your hard disk.
Nothing else. I will NOT be liable for ANY damages, direct or indirect,
that using CleanOut might cause you.
To make my point very, very clear:
If you are a real big echomail server, and CleanOut kills 180 megabytes of
outgoing ArcMail for your downlinks, it ain't my fault. If it also kills
your business data files for good measure, and you consequently get taxed
double the usual rate and lose all of your customers as well, it ain't my
fault either.
ALWAYS test CleanOut by running it in simulation mode when you set it up
for the first time or change your configuration. NEVER tell it about any
other directories whose contents you would like to keep.
CleanOut is copyrighted. I retain all rights on this program and the
documentation.
All brand and product names mentioned in this document are trademarks or
registered trademarks of their respective holders.
┌─────┬────────────────────────────────────────────────────────────────┐
│ 5 │ CONCEPTS (The real docs start here, folks) │
└─────┴────────────────────────────────────────────────────────────────┘
Why, fer Gossake???
───────────────────
If you belong to those sysops who at some time decided to switch from a
FrontDoor-style mailer to Binkley or a similar mailer, you'll probably know
the feeling. Everything that used to be so easy is VERY different now.
Binkley-style mailers have a totally different way of handling their
outbound, and it takes some getting used to.
One difference is that a lot of nice tools won't work with a Binkley-style
outbound. Actually, the main motivation for writing this program was that
the world's best netmail tracker and all-round handy tool for FidoNet
sysops, O/T-Track (written by Peter Hampf), has a few very nice features
built in that will only work if you use a FrontDoor-style mailer.
One of them will look into a directory, find all files that lie around
there, and check if your mailer knows about them (by scanning the attach
messages in your FD netmail folder). If the files aren't found in the
subject of an attach message, they get killed.
This function of O/T-Track only works with mailers that use a dynamic
outbound with netmail attach messages. As I can't seem to convince Peter
of switching to another mailer <grin>, and several people with Binkley-
style mailers have asked for such a baby, well, here's an equivalent for
O/T's MAINT function especially for Binkley-style outbounds. (Thunderous
round of applause)
Also implemented is an equivalent to the /NUKE function, which deletes
old mail for lazy downlinks. It works based on the date of the flow
files. A problem here is that most mail and file processors will
"touch" flow files when adding new lines. That's where the accompanying
tool, FlowAge, comes in -- run it before and after tossing, and it will
keep the DOS time stamp of your flow files at a "real" value.
What does it do, and how?
─────────────────────────
Simply put, CleanOut will scan your mailer's outbound directories for all
files and check if they belong there. If they don't, they get zapped.
That's it.
Now we get to the question: "Which files belong there?" I already said
that we assume you to be familiar with Binkley-style outbounds, so we'll
cut this a little short. Outbound directories should ONLY contain files
that are of some significance to your mailer, nothing else.
Among these files are:
■ Outgoing mail packets. These are files that usually have extensions such
as .OUT, .HUT etc. These files, when sent out, will arrive as .PKT on
the other side.
■ Flow files. These are files that contain a list of other files that are
destined for a certain other node. Usually they have extensions such as
.FLO, .CLO etc. Your mailer uses these files for finding out what files
a certain node should get, and if it should wait for this node to call
in, or send the stuff directly.
Outgoing mail packets and flow files always reflect part of the address
of the node they're going to by means of their file name, which consists
of hexadecimal representations of the net and node number of the
destination node.
Each of those hexadecimal representations takes up four characters, which
is the reason why you need different directories for different zones in
order to be able to distinguish between, for example, zone 2 and zone 6.
■ ArcMail bundles. These are archived echomail packets that are ready for
pickup by one of your up- or downlinks. They carry extensions such as
.SU0, .SU1, .MO4, .TUA etc. An ArcMail bundle is always listed in a flow
file for a specific node.
■ Other files with any filename that should be sent to a certain node.
These files are also always listed in a flow file for a specific node.
■ Mailer-specific files that contain information about how often a certain
node has been dialed without getting a connect, how many failed connects
with a certain node there have been, etc. Their file names and
extensions vary from mailer to mailer.
This covers about everything that should legally show up somewhere in your
outbound directories. There should be no other files in your outbound.
Sometimes though, there will be an additional file there for some reason.
Be it that you copied it into your outbound in order to send it to someone
and forgot to delete it later ... or that you configured your file tosser
to copy outgoing files for your downlinks into an outbound directory (but
it doesn't clean up after the file has been sent to the last downlink) ...
or one of your downlinks has stopped polling you, but there's still a huge
ArcMail bundle lying around for him ... etc. etc.
Here's where CleanOut comes in. It makes a list of all files in your
outbound directories and checks if they are listed in one of the flow
files.
If a file is NOT listed in a flow file, that means it simply doesn't belong
there, and should be killed. And that's what CleanOut does. It takes just
a few seconds to scan through your outbound and zap those unwanted files.
Exceptions
──────────
Of course, CleanOut will leave those files alone that your mailer needs for
correct operation. What we are hunting for is those ZIP files that were
forgotten, and those stray ArcMail bundles that aren't going to be picked
up by anyone any more. We kill these, and then everyone is merry and just
having a great time.
Files that CleanOut NEVER touches are:
■ *.REQ files - that might be outgoing file requests.
■ ArcMail files with a size of 0 bytes, even if you tell it to kill
ArcMail. Your tosser needs these 0-byte files and should delete them
by itself.
■ Files in which your mailer keeps important information, such as *.#??,
*.&??, *.$??, *.-??, *.!??, *.#??, *.Z.
■ *.BSY files that indicate a mail session is currently in progress. On
detecting a *.BSY file in your outbound, CleanOut will immediately
abort before killing any files. This is for security reasons, and I will
NOT change it. The best thing, anyway, is to run CleanOut just once a
day when all mailer tasks are down, for example in your nightly
maintenance.
■ Flow files themselves.
Some mailers such as PoP, Xenia and McMail use an "extended" Binkley-
style outbound. For example, they understand the "immediate" netmail
attribute and start dialing out right away, no matter what. In this
case, we have a flow file that's called ????????.ILO. CleanOut knows
these files and will handle them in the same way as any other flow file.
The currently known file extensions for flow files are:
.HLO .DLO .CLO .ILO .SLO .WLO .PLO .FLO
The currently known file extensions for packets (uncompressed outgoing
mail) are:
.HUT .DUT .CUT .IUT .SUT .WUT .PUT .OUT
If your mailer uses other file extensions, please let me know.
Deleting old files
──────────────────
CleanOut can optionally kill old ArcMail and attached files that your
downlinks are too lazy to poll for. This is done by checking the age of
all flow files. If a flow file is older than the maximum age specified
by you (the hardcoded minimum value is 14 days), CleanOut can delete it.
After the flow file has been deleted, the files referenced in it will be
orphaned ... and, you guessed it, killed by CleanOut. If you tell
CleanOut that it is allowed to delete ArcMail, this goes for old mail
bundles as well.
CleanOut can also write warning messages to lazy downlinks, a few days
before their stuff will get nuked. It can even readdress those messages
to other FTN addresses where those folks can be reached.
CleanOut is multi-tasker aware
──────────────────────────────
CleanOut detects whether a file that it wants to delete is currently in use
by another task. It does that by trying to open it in "Write/Deny All"
access mode and closing it again immediately, right before attempting to
delete it. If a file is currently locked, CleanOut skips it, and continues
with the next file.
CleanOut detects whether it is running under OS/2 or DesqView, and
releases time slices accordingly.
┌─────┬────────────────────────────────────────────────────────────────┐
│ 6 │ SETTING THINGS UP │
└─────┴────────────────────────────────────────────────────────────────┘
Before using CleanOut for the first time, you must configure it. This is
done by editing the sample configuration file CLEANOUT.CFG with any ASCII
text editor.
When you run CleanOut, it finds the config file by looking in the current
directory first. If it's not there, it looks in the directory in which
CLEANOUT.EXE resides.
As usual with most ASCII config files, you can put in as many comments as
you like. In this case, the first character on the line must be a
semi-colon ";". CleanOut will ignore comment lines. All it looks for are
certain keywords that control its behaviour. These are described below.
Checking is not case sensitive, so you can mix capitals and small letters.
NAME <your_name>
────────────────
Specify your name here, and replace spaces with underscores. This is
needed if you want CleanOut to write notification netmail messages.
Example:
Name Klaus_Nitsche
ADDRESS <one or more of your FTN addresses>
───────────────────────────────────────────
With this keyword, you specify your FTN addresses. It is MANDATORY that
you enter at least one address.
With this keyword, you specify your FTN addresses. Again, this is
needed only if you want CleanOut to send netmail.
The FIRST address should be the main address under which you run your
mailer, tosser, etc. Then, you should specify an additional address for
each Fido Technology Net that you belong to, so that CleanOut can choose
the correct address when sending netmail to your downlinks.
You shouldn't enter more than one address per net. CleanOut will pick
the first matching address when writing netmail.
Example:
Address 2:2461/161 ; my main Fidonet address
Address 2:2461/162 ; will *not* be used because there's
already an address for zone 2
Address 246:6104/0 ; my main PB-Net address
Address 111:222/7 ; my main MZ-Net address
NETMAILDIR <your main netmail directory>
────────────────────────────────────────
Specify your main netmail folder here. The path given must point to a
valid directory.
Example:
NetmailDir g:\bink\netmail
KILLNETMAIL YES | NO (Default: No)
────────────────────────────────────
This switch enables you to set the "kill/sent" flag on EVERY outgoing
netmail message.
SIMULATE YES | NO (Default: Yes)
──────────────────────────────────
This is the master on/off switch.
If you specify YES, CleanOut will NOT kill any files. Use this to test
CleanOut on your system. The output will appear as usual and will show
you the files that CleanOut WOULD have killed if we had been serious
here.
When you run CleanOut in simulation mode, you should also enable logging
(see below) and study the log file afterwards. If you're satisfied with
the results (i.e. CleanOut doesn't want to kill any files that you want
to keep), you can set SIMULATE to NO. That's when CleanOut gets nasty
and starts killing files.
LOGFILE <valid file specification>
───────────────────────────────────
Logging will only be done if you enter a valid filename for the log file
here. If you leave this keyword out, CleanOut will not log its activity
to disk.
The file specification can consist of just a filename, in which case the
log file will be created in the current directory. If you enter a full
<drive:\path\filename> specification, CleanOut will put its log file
there.
Examples:
LogFile cleanout.log ; will put it in the current directory
LogFile x:\blah\bozo.log ; will create BOZO.LOG in the path
; X:\BLAH\ if this directory exists
If the file you specified exists already, it will be appended to.
If you give CleanOut an invalid file specification, you get an error
message, and the program refuses to run.
LOGLEVEL MININUM | MEDIUM | HEAVY (default: Medium)
─────────────────────────────────────────────────────
If you have activated logging by specifying a log file above, use this
keyword to indicate how much information should be written to the log file.
Minimum will log only the most important information.
Medium will log some more information.
Heavy will log ALL information including the filenames of all files that
are checked. This will increase the size of your log file
considerably. Use "Heavy" when testing CleanOut.
KILLARCMAIL YES | NO (Default: No)
────────────────────────────────────
Normally, CleanOut will leave all ArcMail bundles (*.SA?, *.SU? etc.)
alone, EVEN if they're not listed in any flow file. (We're playing it safe
here.)
If you specify YES, it will check if those bundles are listed in one of the
.?LO files in your outbound directories. If it doesn't find a reference,
ArcMail bundles that are NOT referenced get KILLED.
CleanOut understands both *.??[0-9] and *.??[A-Z] naming conventions for
ArcMail bundles.
There's one exception here. Even if you specify YES, CleanOut will leave
ArcMail files with a file size of 0 bytes alone - because your echomail
processor needs them! Deleting those files is your echomail processor's
responsibility.
KILLHIDSYS YES | NO (Default: No)
───────────────────────────────────
Specifies whether CleanOut is allowed to delete files that have the
"Hidden", "System" or "Read-only" attribute set.
KILLROOT YES | NO (Default: No)
─────────────────────────────────
This is an additional security step. By default, CleanOut will never
delete files from a root directory (such as C:\ or D:\). If you DO want to
specify such a root directory below, you MUST also enable this switch.
This is to keep you "I'll shoot before I ask" guys from finishing off your
system files in C:\ <grin>.
NEVERKILL <file name>
─────────────────────
This keyword allows you to specify names of files that CleanOut should
not delete. This might be useful in some situations.
Specify just the file name (without path). Wildcards are not allowed.
Example:
NeverKill descript.ion
NeverKill files.bbs
NUKEDAYS <number of days>
─────────────────────────
With this keyword, you can teach your downlinks a lesson. <grin>
Are you running a big system with lots of downlinks? If so, has it ever
happened that some lazy guy didn't poll you in weeks and his stuff kept
piling up in your outbound, taking precious disk space? Here's the
solution. Specify the maximum number of days that a flow file may be
old. If it's older, CleanOut will delete it. And, of course, the files
that were referenced in it, if they are not listed in another flow file.
If you want to delete mail bundles for the lazy downlink, don't forget
to specify "KillArcMail Yes".
The hardcoded minimum number of days you can specify here is 14. You
*can* give a lower number, but then manual interaction will be required
when CleanOut runs. It will ask you if you are REALLY sure that you
want to delete flow files that young, and if you don't press "Y" within
20 seconds, it will default to 14 days.
To make this feature work reliably, you will need to use FlowAge, the
accompanying tool to CleanOut (also in the distribution archive). It
prevents your mail and file processors from changing the date on flow
files. For more information on FlowAge, see chapter 7 below.
If you don't specify the keyword "NukeDays", no age checking will be
done.
A note on the outgoing netmail messages that CleanOut creates: If you
run it in simulation mode, those messages will be locked to prevent them
from going out. They will have the DOS attribute "read-only" and a
hidden line "FLAGS LOK".
Example:
NukeDays 21
NUKEEXCEPTION <FTN address>
───────────────────────────
You want to nuke old stuff for most of your downlinks but want to spare
the packets for a guy who is on holiday for a few weeks? Nothing easier
than that. With this keyword, you can specify addresses whose stuff
will NOT be deleted.
Example:
NukeException 2:2461/161.3
NukeException 246:6104/1200
NukeException 246:6104/1300
NukeException 111:222/7.10
WARNDAYS <number of days>
─────────────────────────
You can instruct CleanOut to warn lazy downlinks a few days before their
stuff is deleted, so they still have a chance to pick it up. Of course,
this number should be lower than the value in "NukeDays". :) CleanOut
will send them a message telling them to hurry up polling for their mail
and files.
The downlinks who are listed under "NukeException" above will not
receive warning messages.
Example:
WarnDays 14
READDRESS <old address> <new address> <optional message flavour>
────────────────────────────────────────────────────────────────
Hmmm. They've stopped polling you, and their stuff will probably get
deleted, but there's not much use sending a message to that very
address, right? They probably wouldn't get it anyway.
But if you know of another FTN address where the lazy downlink might be
reached, you can enter it here, and CleanOut will remap the message to
the new address. (Picking the one of your AKAs that matches as the
sender address, of course.)
The "optional message flavour" can be any combination of the words
CRASH (make this message a crash mail),
KILL (delete this message after sending), or
HOLD (put this message on hold for pickup).
Example:
Readdress 2:2461/161.2 2:241/1090 Crash Kill
Readdress 246:6104/1300 2:2454/420
OUTBOUND <full drive:path specification>
─────────────────────────────────────────
I'm too lazy to implement an intelligent routine that finds your outbound
directories on its own and maybe even recognizes domains. Sorry. That
means that you have to enter ALL your outbound directories manually. (A
trailing backslash is not necessary but doesn't hurt either.)
CleanOut does NOT recurse through directories, so you have to enter ALL
subdirectories as well. (Point directories!)
CleanOut will search these directories for *.?LO files. It will also check
if any OTHER file in these directories is referenced in a *.?LO file, and
if not, zap it.
The important thing to remember is that *.?LO files are read ONLY from the
outbound directories that you explicitly specify here. So if you forget to
enter an outbound directory here, CleanOut will miss the information from
the flow files in it, and is very likely to kill files that are referenced
in them!!
Another short note: if CleanOut can't find ANY flow files in ALL of
your outbound directories, it will abort without doing any harm. That's
because its built-in LASER (Logically-enhanced Artificial Semi-
Intelligence Evaluation Routine) concludes that you probably
specified wrong directories and it's better to be safe than sorry.
(A normal outbound ALWAYS contains at least one or two flow files
somewhere.)
Examples:
Outbound d:\bink\out
Outbound d:\bink\out\000a0001.pnt
Outbound d:\bink\out.0f6\
Outbound d:\bink\alternet.0f6
SCANALSO <full drive:path specification>
─────────────────────────────────────────
You can specify a few additional directories here which you want checked
for files that should be deleted.
Why? Simple. If you use an extra "queue" directory for outgoing files,
for example (some file tossers support that), or some kind of "private"
directories for certain downlinks, you can let CleanOut scan those
directories as well and delete files there that don't show up in any *.?LO
file in your regular outbound.
CleanOut will NOT read *.?LO files here - a flow file should only occur in
your regular outbound anyway. These directories are only scanned for files
to kill.
Examples:
ScanAlso d:\bink\out\attach
ScanAlso d:\bink\out\passthru\
ScanAlso d:\bink\out\ticfiles
That's it. Once you've entered all the information correctly (remember to
specify SIMULATE YES the first time), save the file and you're ready to go.
Fire up CleanOut, watch it scan through your directories, and then study
its log file to see if anything went wrong.
Happy Killing! <grin>
┌─────┬────────────────────────────────────────────────────────────────┐
│ 7 │ KEEPING FLOW FILES AT THEIR CORRECT AGE │
└─────┴────────────────────────────────────────────────────────────────┘
A big problem with Binkley-style outbounds is that you can't judge the
real age of a flow file from its DOS time stamp. Each time your mail or
file processor adds a new line to a flow file, the DOS time stamp is
"touched" to the current date and time.
That, of course, interferes with the "NukeDays" and "WarnDays" stuff.
To make these functions work reliably, I've included another tool called
FlowAge.
FlowAge takes one of two command line parameters, INIT or RESET. You
should run FLOWAGE INIT before running any process that might affect the
time stamps of flow files, such as mail or file processing. It will
make a snapshot of the flow files in your outbound and remember their
date and time stamps. Then, when you're done processing, run FLOWAGE
RESET as the last program in your batch file to reset the dates of the
flow files to what they were before.
So, a typical mail processing batch file would look like this:
───────────────────────────────
@echo off
flowage INIT <-- before anything else happens
fastecho toss -c
feutil link -hmb -jam
... (other stuff)
flowage RESET <-- the very last command after tossing
───────────────────────────────
FlowAge needs CleanOut's configuration file, of course, to find your
outbound directories and the flow files in them. To avoid problems,
keep FlowAge in the same directory as CleanOut.
A note for multiline systems. FlowAge works in such a way that it
creates a temporary file during the INIT run. It uses that file during
the RESET run, and deletes it afterwards. It is your responsibility to
ensure that FlowAge can find its temporary file.
What I mean is, you could run into trouble if you allow tossing on
several lines simultaneously. (This would not only confuse FlowAge, but
other mail/file processing utilities as well.)
The ONLY safe way to process mail and files in a multiline environment
is to run only ONE processing batch at the same time. If you haven't
done so already, you should seriously consider using semaphores to
ensure that a second tossing batch (that might be called shortly after
the first one) exits immediately if it detects that it is already
running.
┌─────┬────────────────────────────────────────────────────────────────┐
│ A │ APPENDIX │
└─────┴────────────────────────────────────────────────────────────────┘
How to reach me
───────────────
If you find a bug in this program, or simply have a suggestion for a future
version, please don't hesitate to contact me. I can be reached at the
following network addresses:
FidoNet: 2:2461/161 (online 24 hours, ZyXEL 16.8) BBS number: +49-6144-92241
2:2461/162 (online 24 hours, ISDN X.75) (no BBS)
PB-Net: 246:6104/1001 (ZyXEL 16.8) (same number as above)
246:6104/1002 (ISDN X.75)
(Routed netmail usually works fine in FidoNet zone 2 and PB-Net,
so it should reach me if your uplinks support it - if they don't,
tell them there's no reason not to!!!)
The above node and phone numbers might be subject to change by the end
of 1995. Please look me up in your nodelist before trying to send me a
message.
Internet: grizzly@ibm.net
I also frequent the echoes OT_SUPPORT (carried on FidoNet, and on PB-Net
as PB-OT) and OT.GER (carried on FidoNet within Germany) which are
concerned with O/T-Track.
The current version of CleanOut is always available for file request
with the magic name CLEANOUT at the following Fidonet systems:
2:2461/161 and 2:2461/162 (The Bear's Cave, Ginsheim, Germany)
1:256/102 (Reptile Ranch, Perth, Ontario, Canada)
1:105/314, 1:105/317, 1:105/330 (Com-Dat BBS, Hillsboro, Oregon, USA)
Reporting bugs
──────────────
If you want to report a bug in CleanOut, or think that it behaves
strangely, please don't just tell me "it doesn't work". I need
*detailed* information to be able to help you. What you need to include
is:
- the operating system, mailer and tosser you are running
- your CLEANOUT.CFG
- the appropriate part of the logfile (with LOGLEVEL set to HEAVY)
- all relevant information about networking software, available memory,
the batch file that calls CleanOut
- whether you can reproduce the error.
Thanks & Credits
────────────────
A big Bear Hug <tm> goes out especially to the following people, who
beta-tested CleanOut (while always running the risk of losing data, but
hey, they trusted me <grin>), and came up with valuable suggestions and
information on how different mailers handle their outbound:
Peter Hampf (also for writing his ingenious O/T-Track and for giving me
very sound advice),
and to Frank Köhler, Mike Roark, Eckhart von dem Berge, Uwe Balser, Matthias
Diehl and Jürgen Fuchs.
You've been a big help, folks.
[EOF]